8장. 클로드 코드에 새 능력 끼우기
출처: 『혼자 공부하는 바이브 코딩 with 클로드 코드』(조태호) | 예제 코드: github.com/taehojo/vibecoding
코드는 분위기만 — npm, npx, SDK 같은 말은 몰라도 됩니다. 표의 '비유'와 '위험'만 봐도 충분해요.
이 장에서 딱 3가지만
- 클로드 코드에 "새 능력"을 끼우는 표준 콘센트가 있다. 그 콘센트 이름이 MCP다.
- 그 콘센트에 자동 테스트·문서 연결·깃허브 같은 부품을 꽂으면, AI가 일을 알아서 끝까지 해 준다.
- 내 컴퓨터에서만 돌던 앱을 인터넷에 올리고(배포), 데이터 창고(데이터베이스)에 연결하면 누구나 쓰는 진짜 서비스가 된다.
학습 목표
이 장을 끝내면 다음을 할 수 있다.
- MCP가 무엇이고 왜 클로드 코드에 끼우는지 설명한다.
- 로컬 MCP와 원격 MCP를 구분한다.
- 배포가 무엇이고 왜 필요한지 설명한다.
- 로컬 스토리지와 클라우드 데이터베이스를 구분한다.
0. 이 장의 새 단어
0장 용어집에 없는, 이 장에서 꼭 필요한 말 세 개만 먼저 풀어 둔다.
각 단어는 [한 문장 뜻 + 일상비유 + 한 줄 예] 3종이다.
막히면 이 박스로 돌아오면 된다.
MCP(엠씨피)
한 문장 뜻 — AI가 바깥 도구·서비스와 연결할 때 쓰는, 모두가 약속한 표준 콘센트(통신 규약).
일상비유 — 220V 콘센트 규격. 선풍기든 노트북이든 플러그 모양만 맞추면 다 꽂힌다. 기기마다 다른 구멍을 뚫을 필요가 없다.
한 줄 예 —
# 클로드 코드라는 본체에, 표준 콘센트로 새 능력을 꽂는다
# > claude mcp add notion ... ← '노션' 능력을 꽂음
배포(deploy)
한 문장 뜻 — 내 컴퓨터에서만 돌던 프로그램을 인터넷 서버에 올려, 컴퓨터를 꺼도 누구나 접속하게 만드는 일.
일상비유 — 집에서 혼자 끓이던 음식을 가게를 열어 파는 것. 내가 자도 가게는 24시간 손님을 받는다.
한 줄 예 —
# 내 컴퓨터 안 → 인터넷 주소로 누구나 접속
# shopping-list.html → 배포 → https://...vercel.app
데이터베이스 / 테이블(database / table)
한 문장 뜻 — 데이터를 표 모양으로 차곡차곡 모아 두는 창고가 데이터베이스, 그 안의 개별 표 한 장이 테이블이다.
일상비유 — 데이터베이스는 엑셀 파일 여러 개를 관리하는 프로그램, 테이블은 그중 시트 한 장. 줄(행) 하나가 항목 하나다.
한 줄 예 —
# shopping_items 라는 표(테이블) 한 장
# | id | name | completed |
# | 1 | 사과 | False | ← 줄 하나 = 항목 하나
이런 적 있죠?
클로드 코드한테 "내 노션에 정리해서 저장해 줘"라고 했더니, "나는 네 노션을 못 만진다"는 답이 온 적 있죠?
AI가 똑똑해도, 바깥 서비스의 문은 잠겨 있다.
노션, 깃허브, 데이터베이스는 각자 자기 문을 따로 잠가 둔다.
그 문마다 맞는 열쇠를 일일이 깎으면 너무 번거롭다.
그래서 "어떤 문이든 이 규격이면 다 열린다"는 표준 열쇠를 정했다.
그 표준이 바로 MCP다.
MCP라는 콘센트에 부품을 꽂으면, AI가 직접 노션에 글을 쓰고, 깃허브에 코드를 올리고, 데이터베이스를 만질 수 있다.
한 문장 정의 — MCP는 AI가 바깥 데이터·도구·서비스와 연결될 때 쓰는 표준 콘센트(통신 규약)이며, 클로드 코드에 MCP를 꽂으면 능력을 거의 무한히 늘릴 수 있다.
개념 1. MCP — 새 능력을 꽂는 표준 콘센트
일상비유 먼저
집에 콘센트가 220V 규격 하나로 통일돼 있다고 하자.
선풍기, 노트북, 충전기 — 플러그 모양만 맞으면 다 꽂힌다.
기기마다 벽에 새 구멍을 뚫지 않아도 된다.
MCP가 바로 이 표준 콘센트다.
클로드 코드(본체)에 노션·깃허브·데이터베이스(기기)를 같은 방식으로 꽂는다.
그럼 클로드 코드가 그 서비스를 직접 만질 수 있게 된다.
비교 상대는 'API'다.
API는 한 서비스 전용 문 하나다. 그 문 하나만 연다.
MCP는 여러 서비스를 같은 콘센트 규격으로 한꺼번에 관리한다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 기기마다 다른 전용 구멍 (API) | 서비스 하나당 따로 연결 | 새 서비스마다 새로 깎아야 함 |
| 220V 표준 콘센트 (MCP) | claude mcp add notion ... |
보안 인증을 빠뜨리면 문이 활짝 열림 |
예시 폭격
예시 1 — 일상.
여행용 멀티 어댑터를 떠올리자.
나라마다 콘센트 모양이 다르지만, 어댑터 하나면 어디서든 충전된다.
MCP는 AI 세계의 멀티 어댑터다. 노션이든 깃허브든 같은 방식으로 끼운다.
예시 2 — 최소 코드. 노션이라는 능력을 꽂는다.
# 터미널에서 이 한 줄이면 클로드 코드에 '노션' 능력이 꽂힌다
# > claude mcp add --transport http notion https://mcp.notion.com/mcp
# 꽂힌 뒤 클로드 코드 안에서 /mcp 라고 치면
# notion 이 "connected" 로 뜨면 성공
꽂힌 다음에는 말로 시키면 된다.
# 이제 클로드 코드가 직접 내 노션에 글을 쓴다
ai.ask("클로드 코드 최신 변경점을 검색·요약해서 노션에 저장해 줘")
또 다른 부품도 같은 방식으로 꽂는다.
큰 문제를 작은 토막으로 쪼개 차근차근 생각하게 돕는 'Sequential Thinking'이라는 부품이 있다.
이름 그대로 "순서대로 생각하기"를 돕는 조수다.
# 어려운 목표를 한 번에 안 풀고, 잘게 쪼개 순서대로 궁리하게 한다
ai.ask("Sequential Thinking MCP로 '체류 시간 2배 늘리기'를 체계적으로 구상해 줘")
# 그냥 시켰을 때보다(예: 85줄) 훨씬 자세한 계획(예: 222줄)이 나온다
# 목표·실행 방법·로드맵·측정 지표·위험 대응까지 단계별로 풀어 준다
이것도 MCP 콘센트에 꽂는 또 하나의 부품일 뿐이다.
예시 3 — 잘못된 예 vs 올바른 예 (before / after).
# 잘못된 예(before): API 한 개로 한 서비스만, 직접 못 만짐
# AI 모델은 노션 파일을 직접 못 건드린다 → "나는 못 한다" 답만 온다
# 올바른 예(after): MCP 콘센트로 AI가 직접 바깥을 만짐
# > claude mcp add github ... # 깃허브 능력 꽂기
# 이제 AI가 직접 코드를 깃허브에 올린다
예시 4 — 부분완성 (빈칸 채우기).
아래 둘 중 클로드 코드가 노션에 글을 직접 쓰려면 무엇이 필요한지 채워 보자.
# (가) 그냥 "노션에 저장해 줘"라고 말만 한다
# (나) 먼저 노션 MCP를 꽂은 뒤 "노션에 저장해 줘"라고 한다
# 노션에 직접 쓰려면 ______ 가 맞다 ((가) / (나))
# 왜냐면 MCP라는 ______ 을(를) 꽂아야 바깥 서비스 문이 열리기 때문이다
빈칸 답 — (나) / 표준 콘센트.
콘센트를 안 꽂으면 AI는 노션이라는 바깥 서비스를 만질 권한이 없기 때문이다.
예시 5 — 독립 적용 (스스로 판단).
다음 둘 중 'MCP의 설명'에 가까운 쪽은?
(가) 한 서비스 하나에 한 연결, 그 서비스 전용 창구.
(나) 하나의 표준 규격으로 검색·DB·여러 API를 한꺼번에 AI에 연결.
답 — (나). MCP는 표준 콘센트라, 여러 서비스를 같은 방식으로 한꺼번에 관리하기 때문이다. (가)는 API의 설명이다.
C = 기본 안전판 — MCP는 바깥 문을 여는 콘센트다. 그래서 보안 인증과 접근 권한을 꼭 챙긴다. 문을 너무 활짝 열면 AI가 만지면 안 될 것까지 만질 수 있으니, 꼭 필요한 권한만 준다.
개념 2. 클라이언트-서버 — 시키는 쪽과 일하는 쪽
일상비유 먼저
식당을 떠올리자.
손님이 주문을 한다. 주방이 음식을 만든다.
손님은 "파스타 주세요"라고 시키기만 한다. 어떻게 만드는지는 주방이 알아서 한다.
클로드 코드가 손님(클라이언트)이다. 시키기만 한다.
MCP 서버가 주방(서버)이다. 실제 일을 한다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 손님 — 주문만 함 (클라이언트) | 클로드 코드가 "저장해 줘" 지시 | 시킨 게 모호하면 엉뚱한 결과 |
| 주방 — 실제 요리 (서버) | MCP 서버가 노션·DB를 실제로 만짐 | 주방이 바깥 파일에 접근 → 권한 관리 필수 |
예시 폭격
예시 1 — 일상.
택배 주문이다.
나는 "이거 보내 줘" 버튼만 누른다(클라이언트).
택배 회사가 차로 옮기고 배달한다(서버).
나는 트럭을 직접 몰지 않는다. 시키기만 한다.
예시 2 — 그림으로 본 흐름.
# 클로드 코드(클라이언트) → MCP 서버 → 실제 서비스
# [클로드 코드] --시킴--> [노션 MCP 서버] --씀--> 노션
# --시킴--> [깃허브 MCP 서버] --올림--> 깃허브
시키는 쪽과 일하는 쪽이 나뉘어 있다.
예시 3 — 이 구조의 좋은 점 (before / after).
# 잘못된 예(before): 클로드 코드가 모든 일을 자기가 직접 한다고 상상
# → 노션 처리법, 깃허브 처리법을 본체가 전부 떠안아야 함 (무겁고 깨지기 쉬움)
# 올바른 예(after): 새 능력은 서버만 꽂으면 끝
# > claude mcp add playwright ... # 자동 테스트 주방을 새로 들임
# 본체는 그대로, 주방(서버)만 늘어난다 → 쉽게 확장
예시 4 — 부분완성 (빈칸 채우기).
# 클로드 코드가 "쇼핑 리스트를 깃허브에 올려 줘"라고 시킨다
# 실제로 git add · commit · push 를 수행하는 쪽은 ______ 이다
# (클로드 코드 / 깃허브 MCP 서버)
# 시키기만 하고 실행은 안 하는 쪽은 ______ 이다
빈칸 답 — 깃허브 MCP 서버 / 클로드 코드.
클로드 코드는 손님처럼 주문만 하고, 서버가 주방처럼 실제 작업을 하기 때문이다.
예시 5 — 독립 적용 (스스로 판단).
새 능력(예: 자동 테스트)을 추가하고 싶다. 무엇을 하면 될까?
(가) 클로드 코드 본체 코드를 뜯어고친다.
(나) 자동 테스트 MCP 서버 하나를 꽂는다.
답 — (나). 본체는 그대로 두고 주방(서버)만 새로 들이면 되기 때문이다. 이게 클라이언트-서버 구조의 가장 큰 장점이다.
C = 기본 안전판 — 본체는 시키기만, 서버가 일한다. 그래서 본체는 가볍고, 서버만 늘리면 능력이 는다. 다만 서버가 바깥 파일·API를 만지니, 권한은 꼭 필요한 만큼만 준다.
개념 3. 로컬 MCP vs 원격 MCP
일상비유 먼저
내 집 주방과 배달 음식을 떠올리자.
내 집 주방(로컬)은 우리 집 안에서 직접 요리한다. 인터넷이 없어도 된다. 더 빠르고, 남이 못 본다.
배달 음식(원격)은 바깥 가게에서 만들어 보낸다. 인터넷이 있어야 한다. 대신 주소(URL)만 대면 연결된다.
로컬 MCP는 내 컴퓨터 안에서 직접 돈다.
원격 MCP는 인터넷 너머 외부 서버에서 돈다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 내 집 주방 (로컬) | claude mcp add ... -s local -- npx ... |
실행 명령을 직접 적어야 함 |
| 배달 음식 (원격) | claude mcp add --transport http ... <URL> |
인터넷·바깥 서버에 의존 |
예시 폭격
예시 1 — 일상.
집밥(로컬)은 재료를 내가 들고 있으니 빠르고 비밀스럽다.
배달(원격)은 주소만 부르면 되니 편하지만, 가게와 인터넷이 살아 있어야 한다.
상황에 따라 골라 쓴다.
예시 2 — 원격 MCP 최소 코드. 주소(URL)만 댄다.
# 원격: URL만 적으면 연결 (배달 주소를 대는 셈)
# > claude mcp add --transport http context7 https://mcp.context7.com/mcp
예시 3 — 로컬 MCP 최소 코드. 실행 명령을 직접 적는다.
# 로컬: 내 컴퓨터에서 직접 돌릴 명령을 적는다
# > claude mcp add sequential-thinking -s local -- npx -y \
# @modelcontextprotocol/server-sequential-thinking@latest
# -s local : 지금 이 프로젝트에서만 쓴다는 범위 지정
# -- : 여기까지는 클로드 옵션, 이 뒤는 실제 실행 명령이라는 구분선
여기서 --가 중요하다.
-- 앞은 클로드 코드에게 주는 옵션이고, 뒤는 "이 명령으로 주방을 켜라"는 실행 명령이다.
예시 4 — 부분완성 (빈칸 채우기).
# 팀과 함께 쓰는 외부 서비스(예: 깃허브)를 연결한다
# 인터넷 너머 서버에 붙으니 이건 ______ MCP 다 (로컬 / 원격)
# 반대로 내 컴퓨터 안에서만 도는 추론 도구는 ______ MCP 다
빈칸 답 — 원격 / 로컬.
외부 서버에 인터넷으로 붙으면 원격, 내 컴퓨터 안에서 직접 돌면 로컬이기 때문이다.
예시 5 — 독립 적용 (스스로 판단).
"인터넷 없이 빠르고, 남에게 안 보이게 개인 작업용으로 쓰고 싶다." 무엇이 맞을까?
(가) 로컬 MCP
(나) 원격 MCP
답 — (가) 로컬 MCP. 내 컴퓨터 안에서 직접 돌아 인터넷이 필요 없고 더 안전하기 때문이다. 팀 협업·외부 서비스 연동이면 (나) 원격이 맞다.
C = 기본 안전판 — 개인 작업·보안이 중요하면 로컬, 팀 협업·외부 서비스면 원격. 둘 다 꽂을 때는 꼭 필요한 권한만 주는 게 기본이다.
개념 4. 자동 테스트·문서 연결·버전 보관 — 일을 끝까지 시키기
일상비유 먼저
자동 세차장을 떠올리자.
차를 넣으면 물 뿌리기·솔질·헹굼·건조를 사람 손 없이 끝까지 한다.
MCP 부품을 꽂으면 개발도 그렇게 된다.
Context7은 "항상 최신 설명서를 곁에 둔 조수"다. AI가 옛 정보로 헛다리 짚지 않게 한다.
Playwright는 "대신 클릭해 주는 로봇 손"이다. 버튼을 눌러 보고 잘 되는지 확인한다.
깃허브 MCP는 "자동 금고 보관"이다. 만든 코드를 안전한 창고에 올려 둔다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 최신 설명서를 든 조수 (Context7) | claude mcp add context7 ... <API키> |
키를 빠뜨리면 연결 안 됨 |
| 대신 클릭하는 로봇 손 (Playwright) | claude mcp add playwright -s local ... |
테스트 결과를 안 보면 헛수고 |
| 자동 금고 보관 (깃허브) | claude mcp add github ... <토큰> |
토큰이 새면 남이 내 코드 만짐 |
예시 폭격
예시 1 — 일상.
요리 후 설거지·정리를 자동으로 해 주는 주방을 상상하자.
만들기(앱 제작) → 검사하기(자동 테스트) → 보관하기(깃허브 저장)가 한 흐름으로 이어진다.
예시 2 — 최소 코드. 쇼핑 리스트 앱을 만들고 자동 테스트한다.
# 1) 앱 만들기
ai.ask("아이템 추가·삭제·체크가 되는 쇼핑 리스트 웹앱을 만들어 줘")
# 2) 로봇 손이 대신 눌러 보며 검사
ai.ask("Playwright MCP로 추가·삭제·체크가 잘 되는지 자동 테스트해 줘")
# → 브라우저를 열어 '사과' 입력·추가·체크·삭제까지 눌러 보고
# .playwright-mcp 폴더에 스크린샷을 남긴다
예시 3 — 깃허브 보관 (before / after).
# 잘못된 예(before): 내 컴퓨터에만 있음
# 컴퓨터가 고장나면 코드가 통째로 사라진다
# 올바른 예(after): 깃허브 MCP로 창고에 보관
ai.ask("github mcp로 shopping-list-app 저장소를 만들고 올려 줘")
# → AI가 add → commit → push 를 알아서 한다
# add: 변경 파일을 준비, commit: 한 묶음으로 기록, push: 창고에 업로드
예시 4 — 부분완성 (빈칸 채우기).
# 깃허브에 올리는 순서는 add → commit → push 다
# add 는 변경 파일을 ______ 에 올린다 (준비 공간 / 원격 창고)
# push 는 묶어 둔 기록을 ______ 에 올린다 (준비 공간 / 원격 창고)
빈칸 답 — 준비 공간 / 원격 창고.
add는 보낼 파일을 준비 공간에 모으고, commit으로 한 묶음 기록한 뒤, push로 원격 창고(깃허브)에 올리기 때문이다.
예시 5 — 독립 적용 (스스로 판단).
"AI가 옛 정보로 헷갈리지 않게, 늘 최신 설명서를 보고 코드를 짜게 하고 싶다." 어떤 부품이 맞을까?
(가) Playwright MCP
(나) Context7 MCP
답 — (나) Context7. 항상 최신 문서를 곁에 두는 조수라, AI가 옛 정보로 헛다리 짚는 걸 막기 때문이다. (가) Playwright는 대신 클릭해 검사하는 로봇 손이다.
C = 기본 안전판 — 토큰·API 키는 '집 열쇠'다. 새 나가면 남이 내 코드·서비스를 만진다. 그래서 안전한 곳에 두고, 유효기간을 짧게(예: 30일) 잡는 게 기본 안전판이다.
개념 5. 배포 — 내 컴퓨터에서 인터넷으로 꺼내기
일상비유 먼저
집에서 혼자 끓이던 음식을 가게를 열어 파는 것을 떠올리자.
집밥은 내가 집에 있을 때만 먹는다. 내가 자거나 외출하면 끝이다.
가게(배포)는 내가 자도 24시간 손님을 받는다.
배포 전 앱은 내 컴퓨터에서만 돈다. 컴퓨터를 끄면 앱도 멈춘다.
배포하면 인터넷 서버에서 24시간 돌고, 누구나 주소로 들어온다.
이 책에서는 Vercel이라는 가게 자리를 빌린다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 집밥 (배포 전) | localhost에서만 열림 |
컴퓨터 끄면 앱도 종료 |
| 가게 오픈 (배포 후) | Vercel이 깃허브를 받아 자동 게시 | 시작 파일 이름이 다르면 404 |
예시 폭격
예시 1 — 일상.
내 방에만 걸어 둔 그림은 나만 본다.
전시장에 걸면(배포) 누구나 와서 본다.
배포는 "내 방 → 전시장"으로 옮기는 일이다.
예시 2 — 배포 흐름 (그림).
# 깃허브에 올림 → Vercel이 자동으로 받아 게시 → 주소 발급
# 내 컴퓨터 → 깃허브 → Vercel → https://...vercel.app (누구나 접속)
깃허브에 올리기만 하면 Vercel이 알아서 가게를 열어 준다.
예시 3 — 흔한 사고: 404 (before / after).
# 잘못된 예(before): 시작 파일 이름이 안 맞음
# Vercel은 'index.html'을 첫 화면으로 찾는다
# 그런데 내 파일은 'shopping-list.html' → "404 Not Found"
# 올바른 예(after): 약속된 이름으로 바꿈
ai.ask("shopping-list.html 을 index.html 로 바꿔 깃허브에 올려 줘")
# → Vercel이 자동 재배포 → 정상 접속
예시 4 — 부분완성 (빈칸 채우기).
# 배포했더니 첫 화면이 "404 Not Found" 다
# Vercel은 첫 화면으로 ______ 파일을 찾는다
# 그래서 내 시작 파일 이름을 그 이름으로 ______ 면 해결된다 (바꾸 / 지우)
빈칸 답 — index.html / 바꾸.
Vercel이 기본 시작 파일로 index.html을 찾는데 파일명이 달라서 못 찾았기 때문이다.
예시 5 — 독립 적용 (스스로 판단).
"친구가 자기 폰에서도 내 앱을 켜 보게 하고 싶다." 무엇이 필요할까?
(가) 그냥 내 컴퓨터에서 켜 둔다.
(나) 깃허브에 올리고 Vercel로 배포해 주소를 알려 준다.
답 — (나). 배포해야 내 컴퓨터를 꺼도 인터넷 주소로 누구나 접속하기 때문이다. (가)는 내 컴퓨터를 끄면 친구도 못 들어온다.
C = 기본 안전판 — 배포는 "내 방 → 전시장"이다. 옮길 때는 약속된 규칙(시작 파일은 index.html)을 지키는 게 기본 안전판이다. 작은 이름 차이가 404를 부른다.
개념 6. 로컬 스토리지 vs 클라우드 데이터베이스
일상비유 먼저
쪽지를 내 책상 서랍에만 넣어 두는 것과, 공용 클라우드 사물함에 넣는 것을 떠올리자.
내 서랍(로컬 스토리지)은 그 책상에서만 꺼낸다. 다른 자리에선 못 본다. 서랍을 비우면 사라진다.
공용 사물함(클라우드 데이터베이스)은 어느 자리에서든, 누구든 같은 사물함을 연다.
로컬 스토리지는 그 브라우저 안에만 데이터를 둔다.
클라우드 데이터베이스는 인터넷 너머 창고에 둬서 어디서나 같은 데이터를 본다.
이 책에서는 Supabase라는 공용 창고를 빌린다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 내 책상 서랍 (로컬 스토리지) | 브라우저 localStorage에 저장 |
다른 기기·시크릿 모드에선 텅 빔 |
| 공용 사물함 (클라우드 DB) | Supabase 테이블에 저장 | 가입·연결 등 첫 준비가 필요 |
예시 폭격
예시 1 — 일상.
내 폰 메모장(로컬)은 그 폰에서만 본다.
공유 문서(클라우드)는 폰·노트북·친구 폰 어디서든 같은 내용을 본다.
데이터가 어디 있느냐의 차이다.
예시 2 — 테이블이 뭔지 (그림).
# shopping_items 테이블 = 엑셀 시트 한 장
# | id | name | completed | created_at |
# | 1 | 사과 | False | 2025-10-29 15:30:00 |
# | 2 | 우유 | True | 2025-10-29 15:32:10 |
# 줄(행) 하나 = 항목 하나, 칸(열) = 그 항목의 정보
예시 3 — 로컬에서 클라우드로 업그레이드 (before / after).
# 잘못된 예(before): 로컬 스토리지에만 저장
# 다른 컴퓨터·시크릿 모드로 들어가면 쇼핑 리스트가 텅 비어 있다
# 올바른 예(after): Supabase 데이터베이스에 저장
ai.ask("Supabase mcp로 shopping_items 테이블을 만들고, "
"로컬 스토리지에 저장하던 걸 데이터베이스로 바꿔 줘. 끝나면 깃허브에 올려 줘")
# → 어느 기기에서 열어도 같은 쇼핑 리스트가 보인다
예시 4 — 부분완성 (빈칸 채우기).
# 노트북에서 '사과'를 넣었는데, 친구 폰에서 열면 안 보인다
# 데이터가 ______ (그 브라우저 안 / 클라우드 창고) 에만 있어서다 → 로컬 스토리지
# 어디서나 같은 데이터를 보려면 ______ 에 저장해야 한다 (그 브라우저 / 클라우드 데이터베이스)
빈칸 답 — 그 브라우저 안 / 클라우드 데이터베이스.
로컬 스토리지는 그 브라우저에만 저장돼 다른 기기에서 못 보지만, 클라우드 데이터베이스는 인터넷 창고에 둬서 어디서나 같기 때문이다.
예시 5 — 독립 적용 (스스로 판단).
"브라우저 캐시를 지워도 쇼핑 리스트가 안 사라지게 하고 싶다." 무엇이 맞을까?
(가) 로컬 스토리지에 계속 둔다.
(나) Supabase 같은 클라우드 데이터베이스로 옮긴다.
답 — (나). 클라우드 데이터베이스는 데이터를 외부 서버가 영구 보관해 캐시를 지워도 남기 때문이다. (가) 로컬 스토리지는 캐시를 지우면 데이터가 사라진다.
C = 기본 안전판 — 혼자 잠깐 쓰면 로컬 스토리지로 충분하다. 여러 기기·여러 사람이 같은 데이터를 봐야 하면 클라우드 데이터베이스가 기본 안전판이다. 단, 가입·키 발급 같은 첫 준비가 한 번 필요하다.
정리
MCP는 클로드 코드에 새 능력을 꽂는 표준 콘센트다.
그 콘센트에 부품을 꽂으면, AI가 직접 노션에 쓰고, 자동으로 테스트하고, 깃허브에 코드를 보관한다.
클로드 코드가 시키는 손님(클라이언트)이고, MCP 서버가 일하는 주방(서버)이다.
로컬 MCP는 내 컴퓨터 안에서, 원격 MCP는 인터넷 너머에서 돈다.
배포는 내 컴퓨터 앱을 인터넷 가게로 꺼내 누구나 쓰게 하는 일이고, 클라우드 데이터베이스는 어디서나 같은 데이터를 보게 해 준다.
기억할 단순 규칙 하나 — 콘센트(MCP)에 부품을 꽂아 능력을 늘리되, 열쇠(권한·토큰)는 꼭 필요한 만큼만 준다.
다음 장 예고 — 다음 장에서는 지금까지 익힌 도구들을 묶어 더 큰 프로젝트를 만들어 본다. (지금 몰라도 됩니다 — 다음 장에서 천천히 풀려요.)
더 학습할 자료
| 자료 | 설명 |
|---|---|
| 클로드 코드 MCP 공식 문서 | MCP를 클로드 코드에 꽂는 공식 안내 |
| Playwright MCP 저장소 | 대신 클릭해 검사하는 자동 테스트 부품 |
| 깃허브 공식 MCP 서버 | 코드 보관(add·commit·push) 자동화 부품 |
| Vercel | 깃허브 코드를 자동으로 게시(배포)하는 가게 자리 |
| Supabase | 가입만 하면 쓰는 클라우드 데이터베이스 창고 |
| 이 책 예제 코드 | 8장 실습 파일 모음 |
클릭하거나 Space를 눌러 뒤집기